Enterprise Modelling

General models of software development focus on analysing data flows and transformation. This kind of modelling only accounts for organisational data and that portion of the process which interacts with the data. The correct integration of information systems in the business administration requires however a more integrated approach to system specification. The re-framed Zachman framework for information systems architecture [7, 5] proposes a layered approach to the specification of information systems, that puts information systems in a much larger context. In the context of this paper we will discuss the second and third layer of this framework, namely the business layer and the service layer. Some specifications may origin from a required business functionality, addressing the essential components of a particular business value chain. Other specifications may address more an administrative type of functionality (including input facilities, generation of output reports, electronic data interchange formatting, as examples), referred to as information services in general. The specifications addressing the first type of functionality constitute an enterprise model (also called business domain model), that contains the relevant domain knowledge for a business administration (including business objects, business events as well as business constraints). Around this enterprise model a service model is developed as a set of input-and output services offering the desired information functionality to the users of the information system. Output services allow the users to extract information from the enterprise model, and present it in a required format on paper, on a workstation or in an electronic format. Input services provide the facilities for adding information or updating information that is relevant for the business administration. As a result, enterprise modelling addresses those issues that are still relevant even if there is no information system. On the other hand, the service or functionality model is concerned with the information system's functionality. However, the service model can be put in the broader context of workflow and business processes. Most current software development methods have no distinction between such business and information functionality. They typically group in a business object not only the core business attributes and business routines, but also input and output procedures. Some methods offer somewhat analogous concepts. Already in [1] the necessity for specifying " real world models " was pioneered. OOSE [2], with some inherited concepts in UML, allows also to distinguish entity objects, as opposed to interface and control objects. In these methods however, the choice …